Updates to Reference Value and Endorsed Values #170
Conversation
Signed-off-by: Yogesh Deshpande <[email protected]>
yogeshbdeshpande
force-pushed
the
updates
branch
from
c56497b to
b3ff139
Compare
| #### X-Triples {#sec-x-triple-rec} | ||
| For the Supply Chain Systems where only incremental updates are possible, it is essential that obsolete or security vulnerable Reference Values and/or Endorsed Values must be removed using x-ref-endor-triple-record. | ||
|
|
||
| The CCDL below, provides schema for remving Reference Values and/or Endorsed Values from a Verifier. |
There was a problem hiding this comment.
| The CCDL below, provides schema for remving Reference Values and/or Endorsed Values from a Verifier. | |
| The CCDL below, provides a schema for removing Reference Values and/or Endorsed Values from a Verifier. |
| @@ -0,0 +1,12 @@ | |||
| update-triple-record = [ | |||
| &(subj: 0) => $subject-type-choice | |||
| & (mval: 1) => [+measurement-values-map] ; object of the update | |||
There was a problem hiding this comment.
Why call it mval if it means "object"?
There was a problem hiding this comment.
because that is triple speak? If not, that's a good question.
| $subject-type-choice /= [+environment-map] ; One or more environment that comprise the subject | ||
| $subject-type-choice /= [+stateful-environment-record] ; One or more stateful-environments that comprise the subject | ||
|
|
||
| $update-action-type-choice /= add ; The new triple causes a new revision identified by measurement-values-map , to be simply updated/added in Verifier |
There was a problem hiding this comment.
The semantics are unclear. Does it mean if the sub statement (with authority authorized-by) matches a statement in the ACS, the object mval modifies the object statements for all the triples named in the sub statement?
Note: If the goal is to replace the triple that matched, including the parts used for matching, then the object seems insufficient (as it needs to replace the environment / stateful environment). Alternatively, a two-step approach could work, where an x-triple removes the triple to be updated and a new triple is added. Note, this operation should be done atomically since the matching condition in the x-triple represents the state / justification for adding the updated triple.
I'm generally concerned that applying an update will cause indeterminate behavior depending on the sequence in which these triples are applied because endorsement triples also depend on the ACS state. These triples might have to be re-processed in order to get the intended (correct) stateful outcome.
There was a problem hiding this comment.
@nedmsmith : The goal of $update-action-type-choice /= add is NOT to remove anything from the Verifier, but to increment.
However, as we are using a common update-triple for any Reference Value and Endorsed Value we have two options:
(a) Specify what is that is been updated by specifying the type - RefVal/EndVal/CondEnd pertaining to the Subject
(b) Rely on the Supply Chain to exactly issue the same triple (like RefVal Triple) OR an EndVal Triple with the new &(action: 3) => $update-action-type-choice and
indicate whether it is an ADD or a REPLACE
Choice:
Option-a: Verifier matches subj and based on the type attaches the new triple to the same subj
Option - b: is Neater but implies modifying every triple where we need an update, to set the action
I would request we focus on the intent of the action and then agree whether to go with option a or option b
There was a problem hiding this comment.
I would request we focus on the intent of the action and then agree whether to go with option a or option b
Maybe this part of the discussion should happen in issue #171 since the conclusion would affect the PR definition.
|
I created issue #194 that makes suggestions for how to approach updates. The x-triples section should probably be moved to a new top level section dealing with update processing. Some of the update processing goals are not unique to x-triples, hence can be described in a way that applies broadly to updates regardless of which update vehicle is used. |
yogeshbdeshpande
changed the title
|
Given it is a non-goal for CoRIM to bias a particular update mechanism / process, we should disposition this PR the same as other approaches by excluding it from the "base" spec. It could be defined behind a profile, or as an extension to the base by a companion I-D. I suggest we label this "wontfix". |
yogeshbdeshpande
added
the
For-next-release
Added relevant issue #171